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DETAILED ACTION 
Claim Objections 

1. Claims 3, 7,8,24 and 29 are objected to because of the following informalities: 

Claim 3 recites, "a CPU" in line 2-3, and "a CPU" in line 4. For clarity, it is suggested to 
insert "resource" between "a CPU" and "and other" in line 2-3. 

Claim 7 recites, "A computer-readable medium contains a program" in line 1 . For 
clarity and to avoid potential U.S.C 101, it is suggested to modify as "A computer-readable 
medium storing a computer program". 

Claim 7 recites, "a new incoming telephone call" in lines 4 and 7. It is unclear whether 
"a new incoming telephone call" in line 7 is the same call recited in line 4. 

Claim 8 recites, "ajiew incoming telephone call" in line 1. It is unclear whether "a new 
incoming telephone call" in line 1 is the same call recited in "a new incoming telephone call" 
claim 7, line 4. 

Claim 24 recites, "the new incoming telephone call" in line 10. It is unclear whether 
"the new incoming telephone call" in line 10 is the same call recited in "an incoming telephone 
call", line 5. 

Claim 29 recites, "a new incoming telephone call" in line 2. It is unclear whether "a 
new incoming telephone call" in line 2 is the same call recited in "an incoming telephone call" 
claim 28, line 4. 

Appropriate corrections are required. 
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Claim Rejections - 35 USC § 112 

2. The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the 
subject matter which the applicant regards as his invention. 

3. Claim 1 is rejected under 35 U.S.C. 1 12, second paragraph, as being incomplete for 
omitting essential elements, such omission amounting to a gap between the elements. See MPEP 
§ 2172.01. The omitted elements are: "a processor receiving both" and "the processor 
setting". 

Claim 1 recites, "a system... comprising: a present Central Processing Unit (CPU) 
utilization value . . . ; a call deny flag ..." in lines 3-6. A system cannot comprise "a present 
Central Processing Unit (CPU) utilization value" unless a CPU/processor receiving and 
processing a CPU utilization value. Likewise, a system cannot comprise "a call deny flag" unless 
a processor/CPU sets such a flag. 

Appropriate correction is required. 

Claim Rejections - 35 USC § 103 

4. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 
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5. Claims 1-4, 7-25 and 28-29 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Shaffer (US 6,41 1,601) in view of Bauer (US00671 1 129B1). 

Regarding claim 1, Shaffer discloses a system for preventing overload of a gateway's 
resources (see FIG. 1-2, gatekeeper 10), said gateway including CPU (see FIG. 3, DSP 
resources) and other resources (see FIG. 3, Network Bandwidth, trunk line resources), said 
system comprising: 

a present Central Processing Unit (CPU) utilization value (see FIG. 4, step 70, level of 
resources requirement for a present call request) and a CPU utilization threshold (see FIG. 4, step 
72, setting level of available resources; see col. 6, line 55-69), said CPU utilization value being 
independent of the utilization of said other resources (see FIG. 3, DSP resources are 
independent/separate from network bandwidth and trunk line resources; camping on DSP 
resource only; see col. 3, line 6-14; see col. 7, line 41-55); 

a call flag (see FIG. 4, sep 74= Y, requirement unsatisfied =Y notification/indication/flag 
is set) when the present CPU utilization value is larger than the CPU utilization threshold (see 
col. 7, line 1-6; when require resource > available resource, unsatisfied 
notification/indication/flag is triggered/set, which indicates a unsatisfactory call software to 
accept or answer); and 

means for detecting (see FIG. 2, resource mechanisms of gatekeeper 10) an incoming call 
(see FIG. 4; see col. 6, line 57-60; see col. 4, line 65 to col. 5, line 6; receiving a call/request), 
and for indicating storing of the incoming call to the incoming call caller when the flag is set, 
(column 7, lines 8-12 and 15-20; the call is placed in a DSP resource queue). 

Shaffer does not explicitly disclose a refusal and deny. 
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However, refusing/rejecting the call due to congestion indication is well known and 
established in the art. In particular, Bauer teaches a processor (see FIG. 1, a combined system of 
memory 130 and CPU 121) setting a call deny flag (see FIG. 2, step 213, 219, and 221; 
unsatisfied/reject or satisfy=N0 notification/indication/flag) when the present CPU utilization 
value is larger than the CPU utilization threshold (see FIG. 3, step 213 with NO, since request 
minimum acceptable resources is larger/greater than available resources, the requested resources 
can not be satisfied); see col. 5, line 25-40; see col. 7, line 1-12); said CPU utilization value 
being independent of the utilization of other resources (see col. 2, line 50-54; see col. 4, line 20- 
30; col. 6, line 60-67; CPU utilizing value "MIPS" are separated from other resources such as 
bandwidth, memory space) and 

the processor detecting an incoming call (see FIG. 3, step 201, a new service request) and 
indicating- refusal of the incoming call to the incoming call caller without answering the 
incoming call when the deny flag is set (see FIG. 2, step 212,219,221; rejecting a new service 
request when unsatisfied/reject or satisfy^NO notification/indication/flag); see col. 5, line 25-40; 
see col. 7, line 1-12. Therefore, it would have been obvious to one having ordinary skill in the art 
at the time the invention was made to provide refusal/rejection due to congestion indication, as 
taught by Bauer in the system of Bauer, so that it would control the utilization of resources in 
real time; see Bauer col. 3, line 4-20. 

Regarding claims 3 and 24, Shaffer discloses a method for preventing overload (see 
FIG. 4, method) in a packet processing device receiving incoming telephone calls, said device 
including a gateway with a CPU and other resources (see FIG. 1-2, gatekeeper 10 receives 
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telephone calls, and gatekeeper comprises a DSP/CPU, Network Bandwidth, trunk line 
resources), said method, comprising: 

setting a Central Processing Unit (CPU) utilization threshold of a CPU of the gateway 
(see FIG. 4, step 72, determining and setting level of available resources; see col. 6, line 55-69; 
see col. 4, line 65 to col. 5, line 6); 

when an incoming telephone call is received (see FIG. 4; see col. 6, line 57-60; see col 4, 
line 65 to col. 5, line 6; receiving a call/request), comparing (see FIG. 4, step 74; comparing; see 
col. 6, line 55-69) a present CPU utilization value (see FIG. 4, step 70, level of resources 
requirement for a present call request) with the entered CPU utilization threshold (see FIG. 4, 
step 72, level of available resources), said CPU utilization value being independent of the 
utilization value of said other resources (see FIG. 3, DSP resources/values are 
independent/separate from network bandwidth and trunk line resources; camping on DSP 
resource only; see col. 3, line 6-14; see col. 7, line 41-55); and 

indicating the incoming telephone call to a caller (see FIG. 4, sep 74=Y, requirement 
unsatisfied =Y notification/indication/flag is set) before the incoming telephone call is answered 
by the packet processing device (column 7, lines 8-12 and 15-20; the call is placed in a DSP 
resource queue) when the present CPU utilization value is larger than the threshold (see col. 7, 
line 1-6; when require resource > available resource, unsatisfied notification/indication/flag is 
triggered/set, which indicates a unsatisfactory call software to accept or answer). 

Shaffer does not explicitly disclose a refusal and deny. 

However, refusing/rejecting the call due to congestion indication is well known and 
established in the art. In particular, Bauer teaches a processor (see FIG. 1, a combined system of 
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memory 130 and CPU 121) setting a call deny flag (see FIG. 2, step 213, 219, and 221; 
unsatisfied/reject or satisfy=N0 notification/indication/flag) when the present CPU utilization 
value is larger than the CPU utilization threshold (see FIG. 3, step 213 with NO, since request 
minimum acceptable resources is larger/greater than available resources, the requested resources 
can not be satisfied); see col. 5, line 25-40; see col. 7, line 1-12); said CPU utilization value 
being independent of the utilization of other resources (see col. 2, line 50-54; see col. 4, line 20- 
30; col. 6, line 60-67; CPU utilizing value "MIPS" are separated from other resources such as 
bandwidth, memory space) and 

the processor detecting an incoming call (see FIG. 3, step 201, a new service request) and 
indicating refusal of the incoming telephone call to the incoming call caller without answering 
the incoming call when the deny flag is set (see FIG. 2, step 212,219,221; rejecting a new service 
request when unsatisfied/reject or satisfy=N0 notification/indication/flag); see col. 5, line 25-40; 
see col. 7, line 1-12. Therefore, it would have been obvious to one having ordinary skill in the art 
at the time the invention was made to provide refusal/rejection due to congestion indication, as 
taught by Bauer in the system of Bauer, so that it would control the utilization of resources in 
real time; see Bauer col. 3, line 4-20. 

Regarding claims 7 and 28, the combined system of Shaffer and Bauer discloses all 
limitation as set forth above in claim 1. Shaffer further discloses gauging software (see FIG. 2, 
software within gatekeeper 10 such as resource availability monitor 42), and Shaffer also 
discloses at least answer the call by accept the incoming call to place in a queue (see col. 7, lines 
8-12 and 15-20; the call is accepted and placed in a DSP resource queue 52). Bauer discloses call 
refusing software (see FIG. 1, admission controller 120 software) refusing the incoming call 
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without answering the incoming call (see FIG. 2, step 212,219,221; rejecting a new service 
request when unsatisfied/reject or satisfy=N0 notification/indication/flag); see col. 5, line 25-40; 
see col. 7, line 1-12). Therefore, it would have been obvious to one having ordinary skill in the 
art at the time the invention was made to provide refusal/rejection due to congestion indication, 
as taught by Bauer in the system of Bauer, for the same motivation as set forth above in claim 1 . 

Regarding claim 15, the combined system of Shaffer and Bauer discloses all limitation 
as set forth above in claim 1 . Shaffer further discloses the processor configured to detect a 
received incoming call (see FIG. 2, FIG. 4; see col. 6, line 57-60; see col. 4, line 65 to col. 5, line 
6; resource mechanisms of gatekeeper 10 detects/receives a call/request) and configured to at 
least answer the call, accept the incoming call to placed in a queue (see col. 7, lines 8-12 and 
15-20; the call is accepted and placed in a DSP resource queue 52). Bauer also discloses deny the 
incoming call (see FIG. 2, step 212,219,221; rejecting a new service request when 
unsatisfied/reject or satisfy=N0 notification/indication/flag); see col. 5, line 25-40; see col. 7, line 
1-12). Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide refusal/rejection due to congestion indication, as taught by 
Bauer in the system of Bauer, for the same motivation as set forth above in claim 1. Therefore, it 
would have been obvious to one having ordinary skill in the art at the time the invention was 
made to provide refusal/rejection due to congestion indication, as taught by Bauer in the system 
of Bauer, for the same motivation as set forth above in claim 1 . 

Regarding claims 2, 4, 16 and 25, the combined system of Shaffer and Bauer discloses 
all limitations. Shaffer discloses wherein the CPU utilization threshold is set to a value of 
available processing capacity of the gateway to ensure calls currently established on the gateway 
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have access to additional gateway processing resources (see col. 6, line 55-69; see col. 4, line 65 
to col. 5, line 6). Setting resource requirements, including processing resources (CPU utilization 
value), to a value lower that the maximum available so as to prevent the processor form working 
at 100% capacity so as to leave some processor capacity as a reserve is well known and 
established in the art. 

In particular, Bauer discloses wherein the CPU utilization threshold is set to a value 
below (see col. 6, line 63 to col. 7, line 1-6; 94 MIPS) a total available processing capacity of the 
gateway (see col. 6, line 63 to col. 7, line 1-6; 100 MIPS) to ensure calls currently established on 
the gateway have access to additional gateway processing resources (see col. 6, line 63 to col. 7, 
line 1-6; 100-94=6 MIPS; to ensure the reserve/additional resource of 6 MIPS). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide refusal/rejection at lower threshold than total capacity, as 
taught by Bauer in the system of Bauer, for the same motivation as stated above in claims 1, 3, 7, 
24 and 28. 

Regarding claim 8, 10, 11, 18, 19, and 29, Shaffer discloses the incoming call input sets 
a ring flag (see FIG. 4; see col. 6, line 57-60; column 6, line 57 - column 7, line 4; see col. 4, line 
65 to col. 5, line 6; a ring/call request/notification/indication/flag is set/triggers) when a new 
incoming telephone call is received (see FIG. 4; see col. 6, line 57-60; see col. 4, line 65 to col. 
5, line 6; receiving a call/request), and the present CPU utilization value input is updated when 
the ring flag is set (see FIG. 4, step 70 determines/updates the DSP resources requirement 
specified in a call request request/notification/indication/flag). Bauer also discloses the incoming 
call input sets a ring flag when a new incoming telephone call is received (see FIG. 2, step 201 ; 
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setting a new call request/ring notification/indication/flag when a new call request/ring is 
received), and the present CPU utilization value input is updated when the ring flag is set (see 
FIG. 2, step 203; determining/updating the request utilization MlPS/resources; see col. 5, line 
20-40; see col. 6, line 60 to col. 7, line 12). 

Regarding claims 9 and 17, Shaffer discloses wherein the CPU utilization threshold is 
set to a pre-specified percent of the total available processing capacity of the gateway (column 6, 
lines 57-63; in order to have any optimal characteristics, Shaffer faced the same tradeoff between 
sound quality and call volume, and thus Shaffer must set the processing threshold to a pre- 
specified percentage). Bauer also discloses the CPU utilization threshold is set to about a pre- 
specified percent of the total available processing capacity of the gateway (see col. 6, line 63 to 
col. 7, line 1-6). 

Regarding claims 12 and 20, the combined system of Shaffer and Bauer discloses all 
limitations. Shaffer discloses wherein the processor detects a ring signal for the incoming call 
(see FIG. 4; see col. 6, line 57-60; column 6, line 57 - column 7, line 4; see col. 4, line 65 to col. 
5, line 6; a ring/call request/notification/indication/signal is set/triggers) and determines the 
incoming call prior to answering the ring signal (column 7, lines 8-12 and 15-20; see FIG. 4, 
decision step 74 in which the resource availability monitor 42 determines whether the required 
level of any resource specified in the call request is above the corresponding availability level for 
the network resource). Bauer also discloses the processor detects a ring signal for the incoming 
call and determines whether or not to refuse the incoming call prior to answering the ring signal 
(see FIG. 2-3, see col. 5, line 1-65; see col. 7, line 1-1 1). Therefore, it would have been obvious 
to one having ordinary skill in the art at the time the invention was made to provide determining 
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whether to refuse the call, as taught by Bauer in the system of Bauer, for the same motivation as 
stated above in claims 1, 3, 7, 24 and 28. 

Regarding claim 13 and 21, Shaffer discloses refusing the incoming call by generating a 
busy signal (see col. 7, line 8-20; in the event that a call request specifies a requested network 
resource level above the corresponding availability levels, a resource reservation mechanism 46 
is invoked, and the call may be placed in a DSP resource queue). Bauer also discloses refusing 
the incoming call by generating a busy signal (see FIG. 2, step 221, notification to the user; see 
col. 5, line 30-40). 

Regarding claim 14 and 22, Bauer discloses the processor does not place refused calls 
in a queue (see FIG. 2, see col. 5, line 30-40; no queues to store call). Therefore, it would have 
been obvious to one having ordinary skill in the art at the time the invention was made to provide 
refusal/rejection at lower threshold than total capacity, as taught by Bauer in the system of 
Bauer, for the same motivation as stated above in claims 1, 3, 7, 24 and 28. 

Regarding claim 23, Shaffer the call may be placed in a DSP resource queue (places 
accepted calls in a queue) (column 7, lines 15-20). 

6. Claims 5, 6, 26 and 27 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Shaffer in view of Bauer, as described above in claims 3 and 24, and further in view of Grewal 
(US005592672A). 

Regarding claims 5 and 26, the combined system of Shaffer and Bauer discloses 
determining a CPU utilization threshold for a CPU as described above in claims 3 and 24. 

Neither Shaffer nor Bauer expressly discloses a bank of CPUs. However, having plurality 
of CPUs or bank of CPUs in the system is well known and established in the art. Grewal 
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discloses determining and distributing in a bank of CPUs (see FIG. 2, plurality of processors 30 
and 32 for processing the calls; see col. 4, line 10-26) Therefore, it would have been obvious to 
one having ordinary skill in the art at the time the invention was made to plurality of CPUs, as 
taught by Grewal in the system of Grewal, so that it would balance the outgoing load; see Grewal 
col. 3, line 29-50; and by having more than one CPU, it would increase the processing capacity 
and capability. 

Moreover, having a bank of CPUs does not define a patentable distinct over that in the 
combined system since both invention as a whole and the combined system are directed to 
processing the calls. The degree in which having a bank of CPUs presents no new or unexpected 
results. If one has one CPU, it will be provide processing capacity and capability, and if one has 
more than one CPU (i.e. bank of CPUs), it will provide more processing capacity and capability. 
Therefore, to have a bank of CPUs that process the calls would have been routine 
experimentation and optimization in the absence of criticality. 

Regarding claims 6 and 27, Bauer disclose setting command, and saving an aspect of 
the setting command in the memory (see FIG. 2, memory 130; see col. 4, line 40-46; see col. 5, 
line 20-30). The combined system of Shaffer, Bauer and Grewal may have selected anyone of a 
variety of memory devices, including an NVRAM, to prevent the loss of information when 
power is lost since it would be impossible to manually enter the instruction every time there is 
power lost. 
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Response to Arguments 

7. Applicant's arguments filed 12/9/2005 have been fully considered but they are not 
persuasive. 

Regarding claims 1-29, the applicant argued that, ". . .there is no teaching in the 
Shaffer reference that a call should be refused if the CPU utilization is above a certain threshold. 
In fact the Shaffer reference specifically states that the monitored examiner the availability level 
of "at least two network resources". . ." see page 9, paragraph 4. 

In response to applicant's arguments against the references individually, one cannot 
show nonobviousness by attacking references individually where the rejections are based on 
combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re 
Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). In this case, the rejection is based 
upon the combination of Shaffer and Bauer, and thus examiner respectfully disagrees with the 
argument above since the combined system of Shaffer and Bauer discloses the agued limitation. 

As set forth in above rejection, Shaffer discloses a call (see FIG. 4; see col. 6, line 57-60; 
see col. 4, line 65 to col. 5, line 6; receiving a call/request) should be stored (column 7, lines 8-12 
and 15-20; the call is placed in a DSP resource queue) if the CPU utilization is above a certain 
threshold (see col. 7, line 1-6; when require resource > available resource, unsatisfied 
notification/indication/flag is triggered/set, which indicates a unsatisfactory call software to 
accept or answer). 

Bauer discloses a call (see FIG. 3, step 201, a new service request) should be refused (see 
FIG. 2, step 212,219,221; rejecting a new service request when unsatisfied/reject or satisfy=N0 
notification/indication/flag) if the CPU utilization is above a certain threshold (see FIG. 3, step 
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213 with NO, since request minimum acceptable resources is larger/greater than available 
resources, the requested resources can not be satisfied); see col. 5, line 25-40; see col. 7, line 1- 
12); see col. 5, line 25-40; see col. 7, line 1-12. 

Regarding applicant argument on "at least two network resource", the application only 
citing a specific portion of the Shaffer disclosure, where indeed Shaffer also disclosure teaches 
"DSP resources only" monitoring scheme. Shaffer discloses where said CPU utilization value 
being independent of the utilization of said other resources (see FIG. 3, DSP resources are 
independent/separate from network bandwidth and trunk line resources; camping on DSP 
resource only; see col. 3, line 6-14; see col. 7, line 41-55). 

Shaffer discloses " a method with DSP resources only" in col. 3, line 6-14 as follows: 

In one embodiment, the method is utilized to camp on to DSP resources only . The 

DSP requirements for a voice-over-data-network call are determined and compared to a level of 
available DSP resources. A reservation for the required DSP resources is requested if the 
required DSP resources exceed the available DSP resources, and the voice-over-data-network 
call is established when the level of available DSP resources meets the required quantities of 
DSP resources. (Emphasis added) 

As discloses above, and it is clear Shaffer teaches utilizing DSP resources only to 
monitor the call request. Thus, the combined system of Shaffer and Bauer clearly discloses the 
claimed invention as set forth above. 

Regarding claims 1-29, the applicant argued that, ". ..Shaffer does not teach the 
desirability of making decisions to reject a call based solely on the fact that the CPU utilization is 
above a certain value..." see page 10, paragraph 1-2. 

In response to applicant's argument, the examiner respectfully disagrees with the 
argument above. Bauer discloses the desirability of making decisions to reject a call based solely 
on the fact that the CPU utilization is above a certain value as stated in above response. Bauer 
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moreover discloses, "decision to reject a call based solely on the fact that CPU utilization is 
above a certain value". Bauer discloses the total resource of CPU/DSP utilization, measured in 
MIPS (Million Instructions Per Second), which is a unit used to measure the speed at which a 
processor/CPU executes instructions (see attached Newton 5 Telecom Dictionary). Thus, it is also 
clear that Bauer also make decision to reject a call based solely on CPU utilization or MIPS is 
above a certain level. 



8. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Ian N. Moore whose telephone number is 571-272-3085. The 
examiner can normally be reached on 9:00 AM- 6:00 PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Doris To can be reached on 571-272-7629. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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